This conversion program will translate a QuickBASIC source code file saved in TEXT format into a source code TEXT file FutureBASIC can use. It will convert approximately 80% of the QB keywords into FB syntax including a majority of CLR and Toolbox calls. It will also convert multi-line IF/THEN statements into FB's LONG IF structures, change multi-statement lines containing colons into single lines. Additionaly, it will convert QB subroutine labels to FB format and convert SUBs into LOCAL FNs.
It also attempts to mark every statement not converted with appropriate references to the Reference or Handbook manuals for help in fixing your source code.
It cannot deduce your program structure. While every attempt has been made to make it as robust as possible in converting parameters, finding labels, and changing SUBs to LOCAL FNs, your method of programming can cause subtle errors to creep into the translated program.
Additionally, it does not attempt to rewrite any file handling routines included in the source file. There are just too many variables to trust an accurate translation and re-writing them is best left to the programmer to ensure the results are what they expect.
ALWAYS WORK ON A TEXT COPY OF THE ORIGINAL.
If errors are present feel free to modify the source code to correct these deficiencies. The source code is provided AS IS with no guarantee of any results. The majority of routines have been documented to provide as much help as possible to make additions or changes relatively easy. Again, feel free to change or modify as necessary to best suit your purposes. If you do, please drop us a copy so that we can share it with others.
If you do modify the program, please append this documentation with any changes, and if distributing it to others, be sure to include ALL the files mentioned above to keep the package complete for the next user.
This program is designed to help you convert the majority of a QuickBASIC program to FutureBASIC format. It does this using several passes through the source code and goes something like this:
Pass 1. Requests you to select a source file to convert (must be in TEXT format), then reads the file into an INDEX$ array, stripping any source remarks as it goes (don't worry, they'll be added back later) into anoth INDEX$ array.
Pass 2. A reference table is created for all GOSUB, GOTO, THEN and inferred THEN label references, and SUB references. All QB labels are converted to FB's double-quote format. Any case variations are accounted for. i.e. Fred and FRED are considered the same. This also applies to SUB references. All SUB references are converted to FN to match FB's subroutine format.
Pass 3: All single line IF/THEN statements and multi-line IF/ELSEIF/END IF lines are reformated into LONG IF/XELSE/END IF format.
Pass 4: Any remaining multi-statement lines are now broken into separate lines.
Pass 5. The next pass is made that converts all incompatable keywords. This is done by accessing the TEXT file called "QB->FB.data". This file can be modified to convert other keywords.
Each keyword to convert requires two sequencial lines in the conversion file. The first line containing the QB syntax, the second the FB syntax. Each QB line is preceded by a special character that identifies the type of keyword to convert. Each parameter is represented by a number, itself preceded by the tilde (~) character.
The keyword codes have the following meanings:
^ (caret symbol, an insert note) Add the text on the next line to the front of the line. For example, in the following:
^CLEAR
• different, see Ref-70 -->
When the conversion program gets to the line "CLEAR 2000" in the QB source file, it will convert it to:
• different, see Ref-70 --> CLEAR 2000
If you attempt the run the converted program, this line will generate a syntax error, forcing you to deal with converting it manually. In most cases the difference between the QB form of the keyword and the FB form can have significant effects on the behavior of the program and should be dealt with manually. For example, QB uses the keyword "LINE" to draw lines and boxes, FB, however, uses "LINE" to return the address of a subroutine in memory.
@ (at symbol, convert w/o parenthesis) This is used with statements that have no paretheses around the parameter list. This directs the conversion program to translate the keyword directly and transfer parameters as indicated. For example, it is used with the LOCATE statement using this format:
@LOCATE ~1,~2
LOCATE ~2,~1
FutureBASIC uses the format horz, vert and QB uses the format vert, horz.
Note the use of the tilde symbol (~) to identify the parameters in the keyword. Use of this symbol in the parameter list ensures that the correct parameter is replaced during the conversion. It is used throughout the data file to identify parameters and by the conversion program to search for parameter matches. Change at your own peril!
# (pound symbol, convert w/parenthesis) This identifies statements that have parentheses around the parameter list. It directs the conversion program to translate the keyword directly and transfer parameters as indicated. It needs to know about the parentheses around the parameters so that parsing is done correctly.
* (asterisk, a toolbox call or function) This is used with the toolbox type commands supported by QB (yes, even Clear Lake's library of stuff). It will convert toolbox commands whether or not they use CALL with parenthesis or no CALL and no parenthesis.
Note that CALL and parenthesis should not be used on the QB conversion line. For example, while CALL FILLPGONHDL (p&, h&) and fillPgonHdl p&,h& are both valid syntax in QB, the format for the conversion text file should be:
*FILLPGONHDL ~1,~2
CALL FILLPOLY(~1,~2)
When dealing with functions, use this format:
*GETICON ~1,~2,~3
~3 = FN GETICON (~2)
In most cases the conversion of QB's toolbox support simply ensures that all procedures that uses CALL have it and that both functions and procedures have parenthesis around the parameter list.
For the Clear Lake Research support, in most cases, they have been converted to the direct toolbox functions or procedures. For example:
Many of the routines have no direct toolbox call, but are instead, a subroutine that performs an action. The qbCLR.INCL file contains about a dozen LOCAL FNs that mimic the effects of some of the CLR routines. For example:
Others have been left to implement at your discretion.
Pass 5: The last pass converts:
1. STATIC subs to LONG FN and non-static SUBs to LOCAL FN. This is generally all that is necessary to convert SUB over. Refer to the FB handbook and reference manual for more information about LOCAL functions.
2. DIM SHARED variables are moved to the globals section of the program (at the top of the program under the "--Globals---" header.
3. OPENRESFILE "filename" statements are moved to the top of the program as: RESOURCES "filename" statement. A note is added to the line so you can check it. In most cases you will probably just remove it as the RESOURCES statements provides direct access to the resource file. In the off chance that your program is accessing more than one resource file you may want to undo this modification.
All QB toolbox commands that access resource files use a ref% number. When the conversion program converts these resource statements it doesn't reference the resource file directly. In most cases this is not needed. However, in the off-chance that the program is accessing multiple resource files, you may require this. Use CALL USERESFILE(ref%) where needed to accomplish this (if you're not doing so already).
There are many examples of converting keywords in the file so you should have no problem understanding it.
The QB to FB conversion program is included as source code so you can modify it if necessary.
FB strings have a maximum of 255 characters. QB strings can be up to 32k. This can obviously cause some problems. Converting this would be treacherous for the program. The best way to do this would be to write LOCAL FN's that work on string handles. Handles are not limited to 32K so you can have strings of any size. If you are using edit fields with text, the text handle is available with TEHANDLE.
Sequential file handling in nearly identical. Random access file handling will require some conversion. We debated about writing an include to do the conversion but the general concensus was that converting manually would be the safest approach to protecting your data.
It is actually easier to do in FB than QB. QB requires that you convert to and from strings using CVI/MKI$ and so on. QB requires use a the FIELD statement to define the position of the data and so on. This is tedious to say the least. Read the file handling section of the Handbook for a complete description of READ and WRITE. You'll be surprised how easy it is.
Random Files are not compatible between the programs. You will need to write a program that converts the random file to a text file (PRINT#) and then use LINE INPUT# to read it into FB. From there, write it back out in FB's compressed random format using READ and WRITE.
------------------------------------------------------- Include files
When using the $INCLUDE meta-command, QB assumes the include file is inserted into that part of the source code. See INCLUDE in the FB reference manual and the Writing programs section of the Handbook for more information about FB Includes. To convert the include file, copy it and paste it into that part of the program where the meta command was. This is the only way to assure all subroutine references are converted correctly.
